Skip to main content

2026-03-05 1854 AEDT

5 mar 2026

UN CEFACT GTR Project - AUS / EU​

Attendees:

Alina Nica Gales

John Phillips

Sankarshan Mukhopadhyay

Jesus san Fernandez

Jo Spencer

Carmen Miquel

Meeting Summary​

The primary focus of this bi-weekly meeting was to step back from technical architecture and align on core conceptual and legal definitions central to the GTR project. The team debated how to define "Authoritative Register," "Authoritative Registrar," and the "Digital Identity Anchor (DIA)." The consensus was to keep definitions as simple and concise as possible, separating the broad definitions of these entities from the specific eligibility requirements needed to participate in the UN/CEFACT grid. The team also reviewed how DIAs should be structured, agreeing they should represent a single identifier rather than wrapping multiple third-party IDs.

Key Decisions​

  • Decouple Definitions from Eligibility: The definition of an "Authoritative Registrar" will be kept separate from the specific eligibility requirements required to join the GTR grid.
  • Keep Definitions Concise: The team agreed to pursue short, precise definitions (e.g., "A body legally empowered to manage, supervise, and maintain an official register...") to avoid confusion and translation issues.
  • Separate "Register" and "Registrar": The definitions must maintain a clear distinction between the Register (the legal list/data of facts) and the Registrar (the body operating or maintaining that list).
  • Atomic DIAs: A Digital Identity Anchor (DIA) should be as simple as possible. It will contain one identifier and one Decentralized Identifier (DID) issued by the Registrar. It will not wrap multiple identifiers (e.g., a local ID, an EUID, and an LEI) to prevent Registrars from assuming liability for identifiers they do not natively control.

Action Items​

  • All Members: Review and comment on the proposed definitions for "Authoritative Register" and "Authoritative Registrar" in GitLab (Issue #44 and #45) before the next meeting.
  • All Members: Review and comment on the proposed changes to the UNTP DIA Specification (Issue #3) regarding single/atomic identifiers.
  • All Members: Review the new placeholder issues for "Implementation Guidelines" and the "Target Operating Model."
  • Alina Nica Gales: Share GitLab repository access links with new member Jesus Sanz Fernandez.
  • Alina / John: Consolidate the feedback on the glossary terms and present the finalized definitions for approval at the meeting in two weeks.

---​

Cleaned Meeting Transcript

Alina Nica Gales: Good morning everyone, and welcome to our bi-weekly meeting of the UN/CEFACT Global Trust Registry Project, 5th of March 2026. As a quick note, today’s meeting will be recorded, including transcripts and chat, and will be made publicly available. Our work takes place under the UN/CEFACT Code of Conduct and IPR policy, encouraging open collaboration.

Until now, much of our work has been focused on technical architecture. However, before moving further, we need to clarify some core legal concepts central to the architecture we are building. Specifically, three concepts: Authoritative Register, Authoritative Registrar, and Digital Identity Anchor (DIA). We want to define which entities are eligible to be listed in the grid to avoid situations where entities outside our scope enter the system. We must also remember we are working within different national jurisdictions, and nothing in this project should interfere with national legal frameworks.

John, I’d be interested to hear your viewpoint on defining these entities.

John Phillips: I think this is a really important point. Looking at Issue #445, I put a thought in the responses: I think we can decouple the definition of an Authoritative Registrar from the eligibility requirements they must meet. If we make the definition of a Registrar for the grid too verbose, with lots of clauses, it becomes difficult. I suggest we have a good, solid legal basis for the term, and then have a separate set of tightly defined eligibility requirements for the current release of the grid. We should make the definition as short as we can, with as few words as possible, to be precise.

Alina Nica Gales: Yes, recently I received proposals from colleagues, including university teachers. One suggestion is: "A body legally empowered to manage, supervise, and maintain an official register for a specific jurisdiction."

Carmen Miquel: I think it's very interesting to have a short definition, but we can't lose two aspects: security and legal certainty. That is the aim of the land registry or commercial registry—to provide legal information supported by the state.

John Phillips: You're absolutely right, Carmen. It's important to get this right. The separation of Registrar and Register is quite deliberate. When we use the word Registrar, we refer to the organization. The Register is the list of facts being recorded. In many countries—like Australia, the UK, and Canada—the body that establishes the register (the government or legislature) is often not the registrar that operates it.

Sankarshan Mukhopadhyay: My approach to definitions has always been to write out in exhaustive detail exactly what we are thinking, and then sequentially pare it down to a point where we say "this is sufficient." Additionally, if somebody needs to translate it, they must know the meaning well enough to translate it cleanly into other languages.

John Phillips: I like that. We accept the baseline you've produced, Alina and Carmen, and see if we can make it shorter without losing any meaning. We also need to be careful not to include qualities of the Register inside the definition of the Registrar. For example, the phrase "mandated to assign, maintain, and certify records" is the role of the body looking after the register, not the register itself.

Alina Nica Gales: Some colleagues asked if we should specify "trade identifiers" in the definition?

John Phillips: I'd be happy not to have that there and have it somewhere else. We are going to define the eligibility requirements for registrars for the grid separately, and those could include terms about trade-related data. I think it's better to remove it from the base definition.

Alina Nica Gales: Okay, moving on, we have another issue: Implementation Guidelines.

John Phillips: Yes, this is a placeholder. We need to create a document that explains how the grid can be established, what types of registration we start with, and how registrars can implement the Digital Identity Anchor. We are also discussing the Target Operating Model—how this works in the real world.

There's also another issue (#447) regarding proposed changes to the UNTP DIA spec. The current spec asks us to consider whether there's a way to improve it. The discussion is centering on the idea that the DIA should be as simple as possible: it should only have one registrar-provided identifier and one DID (Decentralized Identifier) from the subject.

Alina Nica Gales: So you mean not wrapping multiple identifiers together?

John Phillips: Exactly. If a company has a local business identifier, an EUID, and an LEI, those are three different identifiers. Each has a slightly different legal meaning and is issued by a different authority. We think having them in separate DIAs is a good idea to avoid confusion. A Registrar shouldn't be wrapping and verifying identifiers they don't actually control or have liability for.

Alina Nica Gales: That makes sense. We are running out of time, so to be pragmatic: I will commit to having this content updated for the implementation guidelines deliverable. I’d like everyone to commit to reviewing these definitions in GitLab over the next two weeks. You can all write comments directly on the issues.

Jesus Sanz Fernandez: Hi, it's a pleasure to be here. I mostly wanted to listen today, but I will be adding more ideas in the future.

Alina Nica Gales: Thank you, Jesus. I will share the GitLab links with you so you can register and view/comment on the documents. Thank you very much, everybody. Hopefully, we will have our homework done by the next meeting in two weeks!

Chat​

00:03:44.020,00:03:47.020

John Phillips: This is the schedule that we are currently working to. The page also includes a description of the deliverables:

https://un.opensource.unicc.org/unece/uncefact/gtr/docs/About/\#schedule

00:04:58.455,00:05:01.455

John Phillips: This is the issue that Alina is discussing: https://opensource.unicc.org/un/unece/uncefact/gtr/-/issues/45

00:37:41.961,00:37:44.961

John Phillips: This is the home page of the rendered content of the project: https://un.opensource.unicc.org/unece/uncefact/gtr/

00:41:40.021,00:41:43.021

Jo Spencer: I totally agree that the registrar is responsible for issuing their own DIAs. This however implies that each registrar is capable of doing this, independently. There are concepts in other credential ecosystems of issuer service agents that support those issuers that need support. If we're going to disallow this as a concept in the GRID, the definitions are correct. But it might slow adoption by some registrars. Otherwise, we may need to bring in the option of an issuer agent.

00:47:00.719,00:47:03.719

Alina Nica Gales: https://opensource.unicc.org/un/unece/uncefact/gtr/-/issues/?sort=created\_date\&state=opened\&first\_page\_size=20

00:48:20.414,00:48:23.414

Alina Nica Gales: Thanks Jo!